home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-rekhter-fibre-channel-01.txt < prev    next >
Encoding:
Text File  |  1993-04-16  |  30.0 KB  |  933 lines
  1.  
  2.  
  3.                            - 1 -
  4.  
  5.  
  6.  
  7. Network Working Group                                      Y. Rekhter
  8. INTERNET DRAFT                 T.J. Watson Research Center, IBM Corp.
  9.                                                                Editor
  10.                                                               4/15/93
  11.                                                          Version 3.12
  12.  
  13.  
  14.                     IP and ARP on Fibre Channel (FC)
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.  
  20.    This document specifies a standard method of encapsulating the
  21.    Internet Protocol (IP) [1] datagrams and Address Resolution Protocol
  22.    (ARP) [2] requests and replies on FC hardware and protocols [3].
  23.  
  24.    This document specifies an IAB standards track protocol for the Internet
  25.    community, and requests discussion and suggestions for improvements.
  26.    Please refer to the current edition of the "IAB Official Protocol
  27.    Standards" for the standardization state and status of this protocol.
  28.    Distribution of this document is unlimited.
  29.  
  30.    This document is an Internet Draft. Internet Drafts are working
  31.    documents of the Internet Engineering Task Force (IETF), its Areas,
  32.    and its Working Groups. Note that other groups may also distribute
  33.    working documents as Internet Drafts.
  34.  
  35.    Internet Drafts are draft documents valid for a maximum of six
  36.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  37.    other documents at any time. It is not appropriate to use Internet
  38.    Drafts as reference material or to cite them other than as a "working
  39.    draft" or "work in progress".
  40.  
  41.  
  42. 1 Acknowledgements
  43.  
  44.  
  45.    This document would not exist without significant contributions of
  46.    Bryan Cook (IBM Corp.), Martin Sachs (IBM Corp.), and Beth Vanderbeck
  47.    (IBM Corp.).  We would also like to thank Greg Nordstrom (IBM Corp.),
  48.    Jerry Rouse (IBM Corp.), Paul Griffiths (IBM Corp.), and Lansing
  49.    Sloan (LLNL) for their review and constructive comments. Certain
  50.    parts of this document were taken from "IP and ARP on HIPPI" [5]
  51.    written by J. Renwick and A.  Nicholson.
  52.  
  53.  
  54. 2 Introduction
  55.  
  56.  
  57.    Fibre Channel [3] describes the point-to-point physical interface,
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Expiration Date October 1993                                    [Page 1]
  64.  
  65.                            - 2 -
  66.  
  67.  
  68.  
  69.    transmission protocol, and signaling protocol of a high-performance
  70.    serial link for support of the higher level protocols associated with
  71.    IP, IPI, SCSI and others.
  72.  
  73.    The Fibre Channel is logically a bidirectional point-to-point serial
  74.    data channel, optimized for transfers of large blocks of data.
  75.    Physically, the Fibre Channel can be an interconnection of multiple
  76.    communication points, called N-ports, interconnected by a switched
  77.    network, called a Fabric, or a point-to-point link.
  78.  
  79.    Fibre Channel is structured as a set of hierarchical functions
  80.    grouped into several levels.  These levels are organized as follows:
  81.  
  82.  
  83.  
  84.        - FC-0 defines the physical portions of the Fibre Channel.
  85.  
  86.        - FC-1 defines the transmission protocol
  87.  
  88.        - FC-2 defines the signaling protocol which includes the frame
  89.          structure, and byte sequence
  90.  
  91.        - FC-3 defines a set of services which are common across multiple
  92.          ports of a node.
  93.  
  94.        - FC-4 defines the channel protocol, or mapping between the lower
  95.          levels of the Fibre Channel and Upper Level Protocols (ULPs).
  96.  
  97.  
  98.    Of these levels, FC-0, FC-1, and FC-2 are integrated into the FC-PH
  99.    document [3]. The reader of this document is assumed to be familiar
  100.    with the relevant parts of the FC-PH document.
  101.  
  102.    A Fibre Channel Node may support one or more N_Ports and one or more
  103.    FC-4s. Each N_Port contains FC-0, FC-1 and FC-2 functions. FC-3
  104.    optionally provides the common services to multiple N_Ports and FC-
  105.    4s.  A single N_Port may support one or more FC-4s.
  106.  
  107.    Although the FC-4 defined by this document can be used by other
  108.    protocol stacks, for convenience, we refer to it herein as the IP
  109.    FC-4. The IP FC-4 defines a mapping between two particular Upper
  110.    Level Protocols (ULPs), IP and ARP, and the lower levels of the Fibre
  111.    Channel.
  112.  
  113.  
  114.  
  115. 3 Scope
  116.  
  117.  
  118.  
  119.    The document focuses solely on the issues related to running IP and
  120.  
  121.  
  122.  
  123.  
  124.  
  125. Expiration Date October 1993                                    [Page 2]
  126.  
  127.                            - 3 -
  128.  
  129.  
  130.  
  131.    ARP as ULPs over FC.
  132.  
  133.    Within the scope of this document are
  134.  
  135.  
  136.        - mechanisms to exchange IP and ARP packets
  137.  
  138.        - constraints on FC-2 Frame Header parameters
  139.  
  140.        - mechanisms to resolve IP address to physical address mapping
  141.  
  142.        - mechanisms to ensure fair access to resources (N_Ports)
  143.  
  144.  
  145.  
  146.  
  147.    All other issues are outside the scope of this document.  In
  148.    particular, the following issues are not discussed in this document.
  149.  
  150.  
  151.  
  152.        - vendor dependent solutions for ARP server
  153.  
  154.        - supporting IP multicast over FC
  155.  
  156.        - network configuration and management
  157.  
  158.        - interaction with other FC-4s (e.g. SCSI) running over the same
  159.          N_Port
  160.  
  161.        - IEEE 802 MAC Layer Bridging
  162.  
  163.        - Full support for IEEE 802.2 LLC
  164.  
  165.  
  166.  
  167.  
  168. 4 Definitions
  169.  
  170.  
  171.    Class 1 service:
  172.       A service which establishes a dedicated connection between
  173.       communicating N_Ports.
  174.  
  175.    Class 2 service:
  176.       A service that multiplexes frames at frame boundaries to or from
  177.       one or more N_Ports with acknowledgement provided.
  178.  
  179.    Class 3 service:
  180.       A service that multiplexes frames at frame boundaries to or from
  181.       one or more N_Ports without acknowledgement.
  182.  
  183.  
  184.  
  185.  
  186.  
  187. Expiration Date October 1993                                    [Page 3]
  188.  
  189.                            - 4 -
  190.  
  191.  
  192.  
  193.    Destination Identifier:
  194.       The address identifier used to indicate the targeted destination
  195.       of the transmitted frame.
  196.  
  197.    Destination N_Port:
  198.       The N_Port to which a frame is targeted.
  199.  
  200.    Exchange:
  201.       The basic mechanism which transfers information consisting of one
  202.       or more related Information Units. An Exchange may span multiple
  203.       Class 1 Dedicated Connections. The Exchange is identified by an
  204.       Originator Exchange Identifier (OX_ID) and a Responder Exchange
  205.       Identifier (RX_ID).
  206.  
  207.    Exchange Identifier:
  208.       A generic reference to OX_ID or RX_ID (see Exchange).
  209.  
  210.    Fabric:
  211.       The entity which interconnects various N_Ports attached to it and
  212.       is capable of routing frames by using only Destination Identifier
  213.       in the FC-2 frame header.
  214.  
  215.    Information Unit:
  216.       An organized collection of one or more Information Categories
  217.       which an Upper Layer Protocol identifies to FC-PH.
  218.  
  219.    Link_Control_Facility:
  220.       A link hardware facility which attaches to an end of a link and
  221.       manages transmission and reception of data. It is contained within
  222.       each N_Port.
  223.  
  224.    Node:
  225.       A collection of one or more N_Ports controlled by a level above
  226.       FC-2.
  227.  
  228.    N_Port:
  229.       A hardware entity which includes a Link_Control_Facility. It may
  230.       act as an Originator, a Responder, or both.
  231.  
  232.    N_Port Identifier:
  233.       A Fabric unique address identifier by which an N_Port is uniquely
  234.       known. The identifier is used in the Source Identifier and
  235.       Destination Identifier fields of a frame.
  236.  
  237.    Originator:
  238.       The logical function associated with an N_Port responsible for
  239.       originating an Exchange.
  240.  
  241.    Process_Associator:
  242.       A value used in the Association_Header to identify a process
  243.       within a node. Process_Associator is the mechanism by which a
  244.  
  245.  
  246.  
  247.  
  248.  
  249. Expiration Date October 1993                                    [Page 4]
  250.  
  251.                            - 5 -
  252.  
  253.  
  254.  
  255.       process is addressed by another communicating process.
  256.  
  257.    Responder:
  258.       The logical function associated with an N_Port responsible for
  259.       supporting the Exchange initiated by the Originator in another
  260.       N_Port.
  261.  
  262.    Source_Identifier:
  263.       The address identifier used to indicate the source of the
  264.       transmitted frame.
  265.  
  266.  
  267. 5 Design Objectives
  268.  
  269.  
  270.  
  271.    This document describes the specific feature sets of a Fibre Channel
  272.    that must be used, so that any conformant Fibre Channel Node
  273.    implementation has some assurance of being able to interoperate at
  274.    the IP level with any other conformant implementation.
  275.  
  276.  
  277. 6 FC-2 Frame Header Parameters
  278.  
  279.  
  280.  
  281.    This document places the following constraints on the value of the
  282.    FC-2 Frame Header fields when used by IP FC-4 (both by IP and by
  283.    ARP).
  284.  
  285.  
  286.        - Routing Bits of the R_CTL field must indicate Device_Data frame
  287.          (0000).
  288.  
  289.        - Information Category of the R_CTL field must indicate
  290.          Unsolicited Data (0100).
  291.  
  292.        - The TYPE field must indicate IEEE 802.2 LLC/SNAP Encapsulation
  293.          (0000 0101).
  294.  
  295.        - The DF_CTL field shall indicate the presence of the
  296.          Network_Header.
  297.  
  298.        - The Abort Sequence Condition of the F_CTL field shall indicate
  299.          in the first data frame of an Exchange  "Abort, Discard policy
  300.          requested".
  301.  
  302.    Use of the IEEE 802.2 LLC/SNAP Encapsulation for IP and ARP
  303.    prescribed by this document shall not be viewed as a hindrance for
  304.    using the same encapsulation technique by other protocol stacks (e.g.
  305.    IPX, AppleTalk).
  306.  
  307.  
  308.  
  309.  
  310.  
  311. Expiration Date October 1993                                    [Page 5]
  312.  
  313.                            - 6 -
  314.  
  315.  
  316.  
  317.    A conformant implementation is required to send the Network_Header.
  318.    When sending an ARP packet the source and destination network
  319.    addresses in the Network_Header may be in IEEE or CCITT format. If
  320.    neither IEEE nor CCITT formats are required, as determined by the
  321.    sender, the Destination Network_Address_Authority and Source
  322.    Network_Address_Authority fields of the Network_Header shall be set
  323.    to zeros.  When sending an IP packet the source and destination
  324.    network addresses in the Network_Header may be in IEEE, CCITT, or IP
  325.    format. If neither IEEE nor CCITT formats are required, as determined
  326.    by the sender, the IP format shall be used.  The procedures for
  327.    determining whether IEEE or CCITT formats are required (either for IP
  328.    or for ARP packets) are outside the scope of this document.  A
  329.    recipient may ignore the content of the Network_Header.
  330.  
  331.    If a node sends IP packets to an N_Port, and the address resolution
  332.    procedure for that N_Port indicates that the N_Port has a non-null
  333.    Initial Process Associator (see Section 9), the node is required to
  334.    use the Association Header on the first Information Unit of an
  335.    Exchange with the value of the Responder Process Associator field of
  336.    the Association Header being set to the value of the Initial Process
  337.    Associator.  Content of the other fields in the Association Header is
  338.    outside the scope of this document.
  339.  
  340.    A conformant implementation may also send the Expiration/Security
  341.    Header. The content of this header is outside the scope of this
  342.    document.
  343.  
  344.    A conformant implementation shall not send the Device Header.
  345.  
  346.    Setting of all other parameters in the FC-2 Frame Header is outside
  347.    the scope of this document.
  348.  
  349.  
  350. 7 Initializing IP Packet Exchange
  351.  
  352.  
  353.    In order for a node attached to a Fabric to be able to send or
  354.    receive IP and/or ARP packets, the node shall establish its operating
  355.    environment with a Fabric, if present, and other destination N_Ports
  356.    with which it communicates. This is accomplished via Fabric Login and
  357.    destination N_Port Login procedures. Either implicit or explicit
  358.    Login procedure is acceptable.
  359.  
  360.    The procedures for a node to obtain its N_Port Identifier(s) (N_Port
  361.    ID(s)) are outside the scope of this document.
  362.  
  363.    Setting of all Common Login Service Parameters is outside the scope
  364.    of this document.
  365.  
  366.    Setting of all N_Port Login Service Parameters for Fabric Login is
  367.    outside the scope of this document.
  368.  
  369.  
  370.  
  371.  
  372.  
  373. Expiration Date October 1993                                    [Page 6]
  374.  
  375.                            - 7 -
  376.  
  377.  
  378.  
  379.    Setting of all N_Port Login Service Parameters for N_Port Login is
  380.    outside the scope of this document.
  381.  
  382.  
  383. 8 Sending IP and ARP packets
  384.  
  385.  
  386.  
  387.    After a node has successfully completed the Fabric Login procedure
  388.    and the Destination N_Port Login procedure, the node shall check the
  389.    responses to the Fabric Login and the N_Port Login.  If the responses
  390.    indicate that the node can communicate with the Fabric and with the
  391.    Destination N_Port, the node may send IP and/or ARP packets to the
  392.    node associated with the Destination N_Port.
  393.  
  394.    A node sends an IP or an ARP packet by forming an Information Unit
  395.    that consists of the IEEE 802.2 LLC and SNAP headers followed by the
  396.    IP (ARP) packet itself.  There is a one-to-one mapping between an IP
  397.    (ARP) packet and an Information Unit.
  398.  
  399.    The fields in the LLC header shall contain the following values.
  400.  
  401.  
  402.        - SSAP (8 bits) shall contain 170 (decimal).
  403.  
  404.        - DSAP (8 bits) shall contain 170 (decimal).
  405.  
  406.        - CTL (8 bits) shall contain 3 (Unnumbered Information).
  407.  
  408.  
  409.    The fields in the SNAP header shall contain the following values.
  410.  
  411.  
  412.        - Organization Code (24 bits) shall be zero.
  413.  
  414.        - EtherType (16 bits) shall be set as defined in Assigned Numbers
  415.          [4] (IP = 2048, ARP = 2054, RARP = 32,821).
  416.  
  417.    The base relative offset for each Information Unit shall be zero.
  418.  
  419.  
  420. 8.1 Use of Exchanges
  421.  
  422.  
  423.    Interchange of the IP (ARP) packets (in the form of Information
  424.    Units) between a pair of N_Ports is coordinated via Exchanges.
  425.  
  426.    To improve performance this document specifies that an Exchange shall
  427.    be used in a unidirectional mode (this is because an Exchange is
  428.    inherently half-duplex).  Only the Exchange Originator is allowed to
  429.    send IP and/or ARP packets.  Thus, to support bidirectional IP
  430.  
  431.  
  432.  
  433.  
  434.  
  435. Expiration Date October 1993                                    [Page 7]
  436.  
  437.                            - 8 -
  438.  
  439.  
  440.  
  441.    traffic between a pair of N_Ports, separate Exchanges are required in
  442.    each direction.
  443.  
  444.    Each N_Port shall originate one or more Exchanges which it uses to
  445.    send IP and/or ARP packets to the other N_Port.  Support for multiple
  446.    concurrent Exchanges is optional.
  447.  
  448.    An Exchange used for IP and/or ARP packets shall be used solely for
  449.    IP and/or ARP packets.
  450.  
  451.  
  452. 8.2 Errors and Exception Conditions at the Exchange Responder
  453.  
  454.  
  455.    If the Stop Sequence protocol is used during IP communication, the
  456.    Information Unit may be discarded by the N_Port or may be passed to
  457.    the IP FC-4 with an indication that it is damaged.  The Sequence
  458.    Recipient provides no indication to the Sequence Initiator as to why
  459.    the sequence was stopped.
  460.  
  461.  
  462.    Whenever the Sequence Recipient terminates an Information Unit with
  463.    the Abort Sequence condition, the Sequence Recipient shall return
  464.    initiative for this Exchange to the Sequence Initiator in the BA_ACC
  465.    response to Abort Sequence.
  466.  
  467.  
  468.  
  469. 8.3 Errors and Exception Conditions at the Exchange Originator
  470.  
  471.  
  472.    If the sending N_Port receives an ACK with the Stop-Sequence
  473.    indication, it performs the Stop-Sequence protocol defined in [3].
  474.    The Information Unit may be retransmitted.  The sending N_Port
  475.    retains Sequence Initiative for this Exchange.
  476.  
  477.    Whenever the sending N_Port receives the BA_ACC response to its
  478.    Abort-Sequence (due to performing the Abort-Sequence protocol) the
  479.    sending N_Port retains Sequence Initiative for this Exchange.  The
  480.    damaged Information Unit may be retransmitted.
  481.  
  482.  
  483. 9 Address Resolution Procedures
  484.  
  485.  
  486.  
  487.    An IP address may correspond to a single N_Port or to a group of
  488.    N_Ports in a single node. In the latter case the group of N_Ports
  489.    associated with a given IP address is required to be attached to the
  490.    same region (see Section 12).
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497. Expiration Date October 1993                                    [Page 8]
  498.  
  499.                            - 9 -
  500.  
  501.  
  502.  
  503.    The method by which a node obtains its own IP address(es) is outside
  504.    the scope of this document.
  505.  
  506.    Conceptually a hardware address used within the context of address
  507.    resolution is formed by a <N_Port Identifier, Initial Process
  508.    Associator> tuple. Address resolution procedure provides mapping
  509.    between <N_Port Identifier, Initial Process Associator> tuples and IP
  510.    addresses. Multiple <N_Port Identifier, Initial Process Associator>
  511.    tuples may be associated with a single IP address.
  512.  
  513.    Each <N_Port Identifier, Initial Process Associator> tuple forms an
  514.    indivisible unit of information. That is, when sending FC-2 Frames an
  515.    N_Port shall not use an N_Port Identifier from one tuple and an
  516.    Initial Process Associator from another tuple.
  517.  
  518.    If an IP address is associated with multiple <N_Port, Initial Process
  519.    Associator> tuples, then procedures for deciding what tuple to use
  520.    are a local matter.
  521.  
  522.    For the purpose of determining the destination <N_Port Identifier,
  523.    Initial Process Associator> tuple(s) associated with the destination
  524.    IP address, or the next hop IP address (if the destination is on a
  525.    different subnet), a node may use the techniques described in Section
  526.    9.1 and in Section 9.2.
  527.  
  528.  
  529. 9.1 Local Mapping
  530.  
  531.  
  532.    A node shall provide the capabilities to maintain local mapping
  533.    between IP addresses and <N_Port Identifier, Initial Process
  534.    Associator> tuples of other nodes attached to the Fabric.  The source
  535.    of the information for constructing such a mapping is outside the
  536.    scope of this document.
  537.  
  538.    A conformant implementation is required to support local mapping
  539.    capabilities.
  540.  
  541.  
  542. 9.2 ARP Server
  543.  
  544.  
  545.    This section describes how the mapping may be realized by using ARP
  546.    [2].
  547.  
  548.    This document assumes that each region (see Section 12) has an entity
  549.    that is capable of performing the mapping. Such an entity is referred
  550.    to as an ARP Server.
  551.  
  552.    The ARP Server maintains mapping between <N_Port Identifier, Initial
  553.    Process Associator> tuples and IP addresses.
  554.  
  555.  
  556.  
  557.  
  558.  
  559. Expiration Date October 1993                                    [Page 9]
  560.  
  561.                            - 10 -
  562.  
  563.  
  564.  
  565.    The ARP request shall contain all the <N_Port Identifier, Initial
  566.    Process Associator> tuples associated with the originator IP address.
  567.    Upon receipt of the ARP request, the ARP Server constructs the ARP
  568.    Reply and sends it back to the node.  The ARP Reply shall contain all
  569.    the <N_Port Identifier, Initial Process Associator> tuples associated
  570.    with the requested IP address.
  571.  
  572.    To provide the ARP Server with the information about mapping between
  573.    <N_Port Identifier, Initial Process Associator> tuples and IP
  574.    addresses of the nodes, a node shall register with the ARP Server its
  575.    IP address(es) and the <N_Port Identifier, Initial Process
  576.    Associator> tuples associated with that IP address(es) immediately
  577.    upon successful completion of the Fabric Login Procedure and Login
  578.    with the ARP Server.
  579.  
  580.    The registration of an IP address shall be accomplished by sending an
  581.    ARP Request to the ARP Server. The ARP Request shall contain the
  582.    requester's own IP address in the ar$tpa field.  The requester shall
  583.    retransmit this ARP Request until it receives an ARP Reply that
  584.    contains all the tuples carried in the ARP Request.
  585.  
  586.    If an N_Port requires the Initial Process Associator to be used for
  587.    the demultiplexing of incoming IP data, then in the ARP registration
  588.    request the Initial Process Associator part of the <N_Port
  589.    Identifier, Initial Process Associator> tuple shall be filled with
  590.    the appropriate value.  Otherwise, a null Initial Process Associator
  591.    shall be used. The information in this request is intended to be
  592.    registered by the ARP Server.
  593.  
  594.    The order in which <N_Port Identifier, Initial Process Associator>
  595.    tuples are listed in the ARP Request/Reply packets is irrelevant.
  596.  
  597.    If an N_Port is connected to another N_Port by a single dedicated
  598.    link (point-to-point topology) and if the Address Resolution Protocol
  599.    is used, then one of the respective N_Ports shall be configured to
  600.    perform the Address Resolution Protocol function.  The same well-
  601.    known N_Port Identifier shall be used for the ARP Server in the
  602.    point-to-point topology case as is used in other cases.  Note that in
  603.    this case, (at least) one of the Nodes shall provide an ARP Server.
  604.    Such a Node shall be able to handle ARP requests (including
  605.    registration) that originate within either node.  Note that this may
  606.    require the well-known N_Port Identifier to be handled internally.
  607.  
  608.    The ARP Server shall use well-known N_Port Identifier of hex
  609.    "FFFFFC".
  610.  
  611.  
  612. 9.2.1 ARP Message Format
  613.  
  614.  
  615.    To provide alignment an N_Port ID (3 octets) is encoded as four
  616.  
  617.  
  618.  
  619.  
  620.  
  621. Expiration Date October 1993                                   [Page 10]
  622.  
  623.                            - 11 -
  624.  
  625.  
  626.  
  627.    octets with the leading octet filled with zeros.
  628.  
  629.    ar$hrd (16 bits) shall contain 18 (decimal).
  630.  
  631.    ar$pro (16 bits) shall contain the IP protocol code 2048 (decimal).
  632.  
  633.    ar$hln (8 bits) in ARP requests shall contain 12 * number of
  634.           <N_Port Identifier, Initial Process Associator> tuples
  635.           associated with the IP address of the requester. In ARP
  636.           replies it shall contain 12 * number of <N_Port Identifier,
  637.           Initial Process Associator> tuples associated with the IP
  638.           address of the ARP Request target.  Note that due to the size
  639.           of the ar$hln field the number of tuples carried in a single
  640.           ARP request/reply is limited to 21.
  641.  
  642.           For ARP requests and for ARP replies the value of this field
  643.           is equal to the length (in octets) of the ar$sha and the
  644.           ar$tha fields (both of these fields have the same length).
  645.  
  646.    ar$pln (8 bits) shall contain 4.
  647.  
  648.    ar$op (16 bits) shall contain 1 for requests, 2 for responses.
  649.  
  650.    ar$sha (variable) in ARP requests shall contain the list of all the
  651.           <N_Port Identifier, Initial Process Associator> tuples
  652.           associated with the requester.  In ARP replies it shall
  653.           contain the list of all the <N_Port Identifier, Initial
  654.           Process Associator> tuples associated with the target of the
  655.           original ARP Request (as specified in the ar$tpa field of an
  656.           ARP Request).
  657.  
  658.    ar$spa (32 bits) in ARP requests shall contain the requester's IP
  659.           address. In ARP replies it shall contain the IP address of the
  660.           ARP Request target.
  661.  
  662.  
  663.    ar$tha (variable) in ARP requests shall be filled with zeros.
  664.           In ARP replies it shall contain an <N_Port Identifier, Initial
  665.           Process Associator> tuple associated with the node which
  666.           originated the ARP Request with the rest of the field, if any,
  667.           being filled with zeros.
  668.  
  669.  
  670.    ar$tpa (32 bits) in ARP requests shall contain the IP address
  671.           of the ARP Request target.  In ARP replies it shall contain
  672.           the IP address of the Node that originated the ARP Request.
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683. Expiration Date October 1993                                   [Page 11]
  684.  
  685.                            - 12 -
  686.  
  687.  
  688.  
  689. 10 Fair Access and Resource Starvation
  690.  
  691.  
  692.  
  693.    The following rules for Exchange management are intended to ensure
  694.    frequent, fair access to a node for which multiple other nodes are
  695.    contending.
  696.  
  697.    An Exchange Originator or an Exchange Responder may terminate an
  698.    Exchange for lack of resources (Exchange Status Blocks).  The
  699.    decision to terminate an Exchange is a local matter.  The procedures
  700.    for terminating an Exchange are defined in [3].
  701.  
  702.    Appendix A contains guidelines for ensuring fair access to an N_Port,
  703.    when the N_Port uses Class 1 service.
  704.  
  705.    If an N_Port is concurrently used by several FC-4s (including IP FC-
  706.    4), then providing fair access and avoiding resource starvation can
  707.    not be addressed by IP FC-4 means only.
  708.  
  709.  
  710. 11 MTU
  711.  
  712.  
  713.    Maximum Transmission Unit (MTU) is defined as the length of the IP
  714.    packet, including IP header, but not including any overhead below IP.
  715.    Conventional LANs have MTU sizes determined by physical layer
  716.    specification.  MTUs may be required simply because the chosen medium
  717.    won't work with larger packets, or they may serve to limit the amount
  718.    of time a node must wait for an opportunity to send a packet.
  719.  
  720.    In IP FC-4 the transmission unit is the Information Unit, not the
  721.    frame.  The N_Port may transmit an Information Unit using multiple
  722.    frames.  The recipient N_Port reassembles the original Information
  723.    Unit before passing it to the upper level.  The maximum size of a
  724.    single Information Unit is limited to 2^32 - 1, which imposes no
  725.    practical limit for networking purposes.  Even so, an N_Port needs an
  726.    MTU so that maximum buffer sizes for Information Units can be
  727.    determined.
  728.  
  729.    The MTU for IP on Fibre Channel is 65280 (decimal) octets.
  730.  
  731.    This value was selected because it allows the IP packet to fit in one
  732.    64K octet buffer with up to 256 octets of overhead. It is also
  733.    consistent with the MTU defined for HIPPI [5].
  734.  
  735.    The maximum overhead is 8 octets at the present time; there are 248
  736.    octets of room for expansion.
  737.  
  738.       IEEE 802.2 LLC/SNAP Headers              8 octets
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745. Expiration Date October 1993                                   [Page 12]
  746.  
  747.                            - 13 -
  748.  
  749.  
  750.  
  751.       Maximum IP packet size (MTU)         65280 octets
  752.  
  753.                                            ------------
  754.  
  755.                            Total           65288 octets (64K - 248)
  756.  
  757.  
  758.  
  759. 12 Forming an IP subnet
  760.  
  761.  
  762.    This document defines a region as a set of N_Ports attached to a
  763.    common Fabric (if Fabric is present), such that any N_Port in the set
  764.    can successfully complete the N_Port Login Procedure and has
  765.    compatible parameters (sufficient to establish and maintain an
  766.    Exchange) with all the other N_Ports in the set. If a Fabric is
  767.    absent then a region is defined as a pair of N_Ports that have
  768.    successfully completed the N_Port Login Procedure and have compatible
  769.    parameters with each other.  Thus, all the nodes associated with the
  770.    N_Ports forming a single region should be able to exchange IP packets
  771.    with each other without any intervening routers.
  772.  
  773.    All the N_Ports that form a single IP subnet shall belong to the same
  774.    region.
  775.  
  776.    For a set of N_Ports attached to a common Fabric not all of the
  777.    N_Ports within the set may be able to communicate with each other.
  778.    This may be due, for example, to different Classes of service
  779.    supported by different ports within the set, thus resulting in
  780.    potentially incompatible sets of the Login parameters. Therefore, a
  781.    set of N_Ports attached to a common Fabric may consist of multiple
  782.    regions.
  783.  
  784.    If an N_Port and the Fabric to which the N_Port is attached support
  785.    multiple Classes of service, then the set of N_Ports with which the
  786.    N_Port can communicate may not have the transitivity property with
  787.    respect to connectivity. For example, the set may have three
  788.    different N_Ports, P1, P2, and P3, such that P2 can communicate with
  789.    P1, P3 can communicate with P1, but P2 and P3 can't communicate with
  790.    each other. Thus, an N_Port may belong to more than one region.
  791.  
  792.    If an N_Port belongs to more than one region, then for each region in
  793.    which the N_Port is intended to support IP the N_Port shall be
  794.    assigned a distinct IP address. A Node that is connected by N_Port(s)
  795.    to, and supports IP addresses on, multiple regions may act either as
  796.    a multihomed host or as a router.  By default such a node shall act
  797.    as a multihomed host.
  798.  
  799.    Procedures for determining the set of N_Ports attached to a common
  800.    Fabric that forms a region are outside the scope of this document.
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807. Expiration Date October 1993                                   [Page 13]
  808.  
  809.                            - 14 -
  810.  
  811.  
  812.  
  813. Appendix A Fair access with Class 1 service
  814.  
  815.  
  816.    The following approach for Class 1 connection management is suggested
  817.    to ensure frequent, fair access to a node for which multiple other
  818.    nodes are contending.
  819.  
  820.    An Exchange Originator should use the Continue Sequence Condition
  821.    bits to indicate to the Exchange Responder whether the Originator has
  822.    more IP/ARP packets to send.  The Responder may use this information
  823.    when making a decision about terminating a Class 1 connection.
  824.  
  825.    An Exchange Originator should attempt to terminate a Class 1
  826.    connection used solely by the IP FC-4 any time it does not have any
  827.    additional IP or ARP packets to send or is unable to send more
  828.    packets, e.g., due to flow or congestion control or excessive
  829.    occurrences of the Stop_Sequence protocol.  Even in the presence of
  830.    additional IP or ARP packets to send an Exchange Originator may
  831.    terminate such a Class 1 connection after some upper bounded time
  832.    interval. The suggested value of this interval is 500 milliseconds.
  833.  
  834.    The purpose of this is to give each Exchange Originator a fair share
  835.    of a common Exchange Responder's bandwidth.  Without a limit, if
  836.    there is a Responder that is constantly in demand by multiple
  837.    Originators, the Originator that sends the most data per connection
  838.    may effectively monopolize the Responder.
  839.  
  840.  
  841. Appendix B Guidelines for using different Classes of service
  842.  
  843.  
  844.    If the Fabric, the Exchange Originator, and the Exchange Responder
  845.    all support Class 1, Class 2 and/or Class 3 service, then the
  846.    Originator is allowed to send data over any Class supported by all.
  847.    To improve performance it is suggested to use Class 1 for sending
  848.    long Information Units, and use Class 2 or 3 for sending the rest,
  849.    unless there is already an established Class 1 connection that can be
  850.    used.
  851.  
  852.    Use of Class 3 service for sending IP packets may have certain
  853.    undesirable performance implications.
  854.  
  855.  
  856. References
  857.  
  858.  
  859.    [1] Postel, J., "Internet Protocol", RFC-791, USC/Information
  860.    Sciences Institute, September 1981.
  861.  
  862.    [2] Plummer, D., "An Ethernet Address Resolution Protocol - or -
  863.    Converting Network Protocol Addresses to 48.bit Ethernet Address for
  864.  
  865.  
  866.  
  867.  
  868.  
  869. Expiration Date October 1993                                   [Page 14]
  870.  
  871.                            - 15 -
  872.  
  873.  
  874.  
  875.    Transmission on Ethernet Hardware", RFC826, MIT, November 1982
  876.  
  877.    [3] "Fibre Channel - Physical and Signaling Interface (FC-PH)", Rev
  878.    3.0, ANSI, June 1992
  879.  
  880.    [4] Reynolds, J.K., Postel, J., "Assigned Numbers", RFC1060,
  881.    USC/Information Sciences Institute, March 1990
  882.  
  883.    [5] Renwick, J., Nicholson, A., "IP and ARP on HIPPI", RFC1374,
  884.    October 1992
  885.  
  886.  
  887.  
  888. Editor's Address
  889.  
  890.    Yakov Rekhter
  891.    T.J. Watson Research Center, IBM Corporation
  892.    P.O. Box 218
  893.    Yorktown Heights, NY 10598
  894.    Phone:  (914) 945-3896
  895.    email:  yakov@watson.ibm.com
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931. Expiration Date October 1993                                   [Page 15]
  932.  
  933.